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Dear Sir: 

I, CHARLES PACLAT DECLARE AND STATE THAT: 

1. I am the inventor of the "Method for Developing Business Components" 
described and claimed in the above-identified U.S. Patent Application ("the Present 
Application")- 

2. I was advised and therefore believe that the Present Application claims the 
benefit of U.S. Provisional Patent Application Serial No. 60/239,409 filed October 11, 
2000 ("the Provisional Application"). 

3. The Present Application was assigned to BE A Systems, Inc. by me on 
December 12, 2001. Exhibit A is a copy of the Notice of Recordation of Assignment 
document evidencing the recordation of the assignment on January 22, 2002. 

4. Well prior to August 24, 2000, the claimed invention shown and described 
in the provisional and present applications was conceived and reduced lo practice. 
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5. Exhibit B is a document written well prior to August 24, 2000 and provides 
an overview of New Component Development Process. Page numbers have been added 
for clarity. For example, the step of "analyzing" as required in the claims is shown on 



step of "building" as required in the claims is shown on pages 13-14, and 16. 
Additionally, for example, these steps are shown together generally on page 7. (The 
actual date has been redacted from this document). 

6. Exhibit C is a document written well prior to August 24 : 2000 that 
describes version 1 . 1 of the New Component Development Process. Page numbers have 
been added for clarity. For example, the step of "analyzing" as required in the claims is 
shown on page 7. the step of "transforming 51 as required in the claims is shown on page 
11, and the step of "building" as required in the claims is shown on pages 14-15. 
Additionally, for example, these steps are show together generally on pages 4, 5, and 6. 
(The actual date has been redacted from this document). 

7. I further declare that all statements made herein of my own knowledge are 
true and that all statements made on information and belief are believed to be true; and 
that these statements were made with the knowledge that willful, false statements and the 
like so made are punishable by fine or imprisonment, or both, under Section 1001 of Title 
18 of the United States Code and that such willful, false statements may jeopardize the 
validity of the applicati on or any patent issuing thereon. 
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Docket Number: THEOR 205.1 US - CM 
ASSIGNMENT 

WHEREAS, I, as a below named inventor, residing at the address stated next to my 
name, am a sole inventor (if only one name is listed below) or a joint inventor (if plural names are 
listed below) of certain new and useful improvements in METHOD FOR DEVELOPING 
BUSINESS COMPONENTS for which an application for Letters Patent of the United States of 
America was executed by me on the date indicated next to my name and address; 

AND WHEREAS, BEA Systems., Inc, with principal offices located 2315 North 
First Street. San Jose, CA 95134 (hereinafter referenced as ASSIGNEE) is' desirous of acquiring 
all interest in, to and under said invention, said application disclosing the invention and in. to and 
under any Letters Patent or similar legal protection which may be granted therefor in the United 
States and in any and all foreign countries; 

NOW THEREFORE, in consideration of the sum of One Dollar ($ 1 .00), and other 
good and valuable consideration, the receipt and sufficiency of which are hereby acknowledged. I ? 
as a sole or joint inventor as indicated below, by these presents do hereby assign, sell and transfer 
unto the said ASSIGNEE, its successors, assigns, and legal representatives, the entire right title and 
interest in the said invention, said application, including any divisions and continuations thereof, and 
in and to any and all Letters Patent of the United States, and countries foreign thereto, which may- 
be granted for said invention, and in and to any and all priority rights and/or convention rights under 
die International Convention for the Protection of Industrial Property, Inter-American Convention 
Relating to Patents, Designs and Industrial Models, and any other international agreements to which. 
t)ie United States of America adheres, and to any other benefits accruing or to accrue to me with 
respect to the filing of applications for patents or securing of patents in the United States and 
countries foreign thereto, and I hereby authorize and request the Commissioner of Patents to issue 
the said United States Letters Patent to said ASSIGNEE, as the assignee of the whole right, title and 
interest thereto; 

And I further agree to execute all necessary or desirable and lawful future document^ 
including assignments in favor of ASSIGNEE or its designee, as ASSIGNEE or its successors, 
assigns and legal representatives may from time-to-time present to me and without further 
remuneration, in order to perfect title in said invention, modifications, and improvements in said 
invention, applications and Letters Patent of the United States and countries foreign theretc; 

And I further agree to properly execute and deliver and without further remuneration, 
such necessary or desirable and lawful papers for application for foreign patents, for filing 
subdivisions of said application for patent, and or. for obtaining any reissue or reissues of any Lsnsn 
patent which may be granted for my aforesaid invention, as the ASSIGNEE thereof shall hereafter 
require and prepare at its own expense; 
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And I further agree that ASSIGNEE will, upon its request, be provided promptly with, 
all pertinent facts and documents relating to said application, said invention and said Letters Patent 
and legal equivalents in foreign countries as may be known and accessible to me and will testily as 
to the same in any interference or litigation related thereto; 

And I hereby covenant that no assignment, sale, agreement or encumbrance has been 
or will be made ox entered into which would conflict with this assignment and sale. 

This assignment executed on the dates indicated below. 
Charles PACLAT 



Name of first or sole inventor 

114 Wolcott Street 

Medford, MA 02155 

Residencpttf rirsjor^ole inventor 




Signature of first or srfie inventor Date of this assignment 
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A PROCESS FOR THE DISCOVERY AND IMPLEMENTATION OF GENERIC BUSINESS 
COMPONENTS 

The New Component Development 



Introduction 



Building Business Objects 

This document outlines a process by which BEA/eSoluuons will create object 
onented representations of the software components that facilitate a vast array ot 
business solunons. It identifies the key steps that are needed to build these 
components and provides guidelines for the order of their execution. Underlying 
the concepts in this document are some key guiding principles that should be kept in 
mind throughout. 

Developing Business Objects 

Developing business objects differs from developing end user applications. The 
traditional end user is the person that is using an applicauon to complete their daily tasks. 
In the case of business objects the end users are software developers and business 
analysts. Ultimately it is these users that will be customizing these components to create 
the complete solunons that the customers demand. 

Business objects also differ from the development of tradinonal software tools and 
infrastructure. This end user in these cases is onlv the software developer. Such tools 
rarely contain business domain specific logic. They can be designed and developed with 
no input from the business domain experts. 

Business object development requires much greater collaborauon between the business 
analvsts and the software engineering teams. The result will be well -structured 
components that capture the most important facets of a business domain. 

Time to Market 

The ability to deliver components in a timely manner is an overriding concern m today s 
extremely competitive marketplace. One of the key premises is that up front research wUl 
allow us to define the segments of the space where we can provide value added and 
where we should form relationships. With this in mind it is important to be thorough 
- but timely in the analysis. The typical up front analysis should consume no more than a 
few weeks. 
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Iterative Development 

It should be stressed that these steps are not to be executed in a rigidly denned sequence. 
The only hard and fast rule is that a thorough market analysis must be done up front. 
This will allow the design and implementation phases to be completed in an environment 
of full disclosure. It is expected that a very scaled back version of the components will 
be delivered after the first iteration. Each of the iterations will provide feed back into the 
analysis and design, and will result in a product that is increasingly complete. 

Flow of Participation 

An important technique that is used in the NCD Process is the overlapping of team 
members as development passes through the various phases. Each phase of development 
will involve participants from the functional organizations that follow it in the process. 



Concept Exploration 




Requirement Analysis 




Architectural Design 




Future Versions 



Dot Versions 



Detailed Design, 
implementation and Test 



Change Requirements 
Analysis 





Analysis Pnase 



Design Pnase 



implementation 
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Concept Exploration 

The initiation of a new suite of components is within the product management team. It is 
important that there be significant contributions from the sales and professional services 
teams. Typical functional representation will be 50% Product Management, 20% 
Professional Services, 15% Sales, and 15% Engineering. 

Requirements Analysts 

The second phase is a more detailed analysis of the functional requirements from a 
standpoint of implementing the functionality of a set of components. Typical functional 
representation will be 60% Product Management and 40% Engineering. 

Architectural Design 

The process of turning the functional requirements into an object oriented model that 
encapsulates the data model and the process model. At this point the weighting shifts to 
75% Engineering and 25% Quality Assurance. 

Detailed Design, Implementation and Test 

This phase consists of a more detailed version of the architectural design, implementation 
of the business logic, and software testing of the components in hand. At this point the 
typical functional representation will be 70% Engineering, 20% Quality Assurance, and 
107o Documentation. 

Deliver Component 

The process of delivering the components in a timely manner into the market place. At 
this point the weighting will be 50% Quality Assurance, 30% Documentation, 20% 
Support, and 10% Engineering. 

Change Reauirements Analysis 

The feedback from the customers is analyzed to incorporate the changes in the newer 
versions of the components. It is important to delegate the required upgrade based upon 
its type (see Appendix A) to the corresponding phase in the process. The typical 
weighting at this point is 60% Support, 20% Sales, and 20% Professional Services. 

Parallel Development 

In man}' cases there are opportunities to improve time to market by performing steps m ^ 
parallel' This is especially true with regard to the implementation of the components and 
the building of the demonstration or prototype application. It is expected that once the 
initial design of the components is complete, the implementation of the components and 
the building of the prototype will provide opportunities for improvement. 

In general the development process will involve parallel iterations of the produce and 
associated demonstration applications. 



5 



Time 



Design Iteration 1 



Design Iteration N 



Prototype 


p~ 


Prototype 


Iteration 1 




Iteration N 



Target Functionality 

In almost all cases our objective is to establish an immediate product presence in the 
Enterprise Java Beans Component market. In many cases this will mean replicating a 
base line product offering in our first iteration. In such cases our advantage will be in the 
f act that we are EJB and that the components are built as eBSCs and are extensible and 
configurable. In follow on iterations we will push past the state of the art and deliver 
functionality that exceeds that of our competitors. 

Versioning of Components 

In all cases, our primary concern is to keep our customers on the newest version of our 
components. The new version might include not only new functionality, but also bug 
fixes to code they already use, performance improvements, support for new platforms 
etc. The versioning scheme for our components tries to make upgrades easy, predictable 
and desirable is described in Appendix A. 

increased Quality 

Tne delivery of high quality software components is an extremely overriding concern ui 
today s market. Use of such reusable software components will result in a system with 
increased duality since these components are pre-fabricated (i.e., pre-implemented) and 
pre-tested (i.e., certified) components. The greater the reuse of a component, the greater 
will be the quality of the system using it since the errors must have been eliminated. 

Reduction in Development Costs 

Increased quality results in decreased development costs. Use of pre-tested reusable 
software components decreases the cost incurred in performing various quality assurance 
activities to detect the errors in the design specifications and implementation. 
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Analyses 

Defining the scope of the business functionality. 

The first phase of each New Component Development undertaking defines the 
scope of the business functionality for a new set of components from the Theory 
Center. This phase involves a small team including one or two member from die 
NCD team and additional domain knowledgeable resources from the 
architecture or professional services teams. The key deliverable from this process is die 
completion of the NCD Definition. 

The NCD Definition is a single document that summarizes research into an enure 
business domain. The "divide and conquer" approach is taken such that once a wide 
reaching NCD is completed it is likely that it will be divided into addinonal sub domains 
that are then recursively refined as NCD's of their own. This process continues until 
manageable units of functionality are arrived at. 

The NCD Definition itself is composed of the following major sections. 

Summary of Scope 

The document begins with an overview of the business problem that is being addressed. 
The purpose of this secuon is to set the context upon which the rest of die research is to 
be completed. The content should address die concerns of a typical end user of the 
targeted solution. The tone should be that of an expert in the field explaining the issues 
to an outsider. 

Lest of inputs 

Once the scope of the business problem is defined, die process of identifying resources 
that relate to the problem are identified, assembled and summarized. The following 
major groupings are specifically addressed. 
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interacting Components 

This section describes components or other parts of the system that this component will 
interact with. It should just be a simple bulleted list of items naming the component and 
what functionality is needed from that component. The list should strive for 
completeness as it will not only be useful for helping readers of this NCD better 
understand the component, but it will also help with cross-NCD dependency tracking. In 
this phase this section might include some components that may or may not actually be 
interacted with. An example section is: 

• Interacts with Inventory component to know what is in stock. 

• Interacts with the Shipping component to determine how much shipping will 
cost. 

• Might use the Payment component to authorize payments, 
industry Analysts 

In many cases analysts have initiated much of the research into a given sector. Gathering 
and reading targeted analysts reports is generally the first step towards gaining an 
understanding of the domain. 

Related industry Standards 

Another prime source of information are standards bodies and or professional societies. 
These organizations represent the contribution of the best thinking in a given domain. 
They often have the aim of publishing standards that represent the functionality common 
across an array of vendors. The collected publications and standards are collected into a 
repository. The list of member companies in such consortiums is a window onto the 
collection of vendors that are offering solutions in a given domain. 

Commercial Packages ( Competitors / Partners ) 

The reference documentation and feature sets of commercial software packages are aisc 
gathered. The superset of the most prominent features is the ultimate solution to the 
problem that is being addressed. The union of the features in these products generally 
represents the baseline functionality for a product offering. During this process it is 
important to foster positive relationships with vendors. In many cases we may simply oe 
providing a generic interface that will be used to wrap third party solutions. Such 
"adapters" are only possible with the cooperation of the partner. 

Related Engagements and System integrators ( Customers ) 

The work that is accomplished in extending our components to meet the needs of our 
customers is one of our best resources. It is for this reason that it is important to include 
representatives from the architectural and professional services teams in this part of the 
process, A corporate knowledge base of documentation from all professional services 
engagements must be maintained and referenced for recoverable intellectual property. 
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Additional in-house Resources ^ 

Many of the companies best resources lies in the past experience of the current staff. For 
this reason it is important to publish the goals of the NOD to the rest of the company 
and elicit input from all interested parties. The presence of such resource should be 
noted and they should be included as advisors during the second phase of the process. 

eFunction Matrix 

Upon completion of the list of inputs the creation of a eFunction matrix is initiated. The 
eFunction matrix is accomplished by first collecting an all encompassing list of features 
from all of the inputs listed. The features, or eFunctions, must be described in a summary 
of less than five words. These eFunctions are collected into groups or packages. Longer 
descriptions are bound to these short descriptions and cross referenced. The 
eFunctions are listed as the first column of a grid. A template of the resulting table is 
presented below. 



eFunction Matrix: Shopping 

Package eFunction |_ 


Status 

iu to iu = nmswifc, 


Importance | 

lu to im = must newt. | 


Difficulty 


Competitors 




| 










CRM 


Provide rnethoa on the buitnea* operation* 
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Fulfillment 


Can pui data lo tba Order Fulfillment aystem 




ID 






Invoicing 


Discount policies cnn be applied at customer level 


0 


7 






Invoicing 


Discount polloiee can be applied at Invoice level 


0 


7 






Invoicing 


Misc. charges can be applied to Invoice or packing list 


c 


7 






Invoicing 


Discounts can M applied lo ttame in cart 




B 






Invoicing 


Total of Items in can can oe calculated 




e 




i 


Invoicing 


Support for terms ot sale 


0 






i 


item 


Items can have dimensions, welpht 


0 


7 






Hem 


Items can have a tax code 


0 


9 






item 


ttema can be added Into shopping cart 




10 






item 


Quantities ot Items in snopptno cart can be updated 




1C 




i 


Item 


Items can be deleted from ine shopping carl 




IP 




! ., 


Order 


Multiple delivery methods 


0 








Oraar 


Allow the purchasing of only a portion of the sboooinp carl 




5 
9 




r 


Order 


bending shipment as a gift 


0 






i 


Order 


Customization ot order cost calculation policy 


10 


9 
1L 






Order 


The syatem works for known users 










Ordor 


The system works tor anonymous user* 




U 




i 


Order 


Special Instructions tor delivery 


0 


6 






Order 


Support tor beck order canoe (1st ion date 


c 


S 






Payments 


Can manage multiple payment methods 










Payments 


Can manage coupons and gift certificates 


0 








Povmeritr 


Can pay with purchase ordert 




6 






Payments 


Can authorize payment methods 




7 








Can menage art leant 1 payment method 




6 
10 






pBvmenls 


Can pay with credit cards 










Shipping 


Exact shipping cost can be oaicutateo 










Shtpoing 


Approximate e hipping cost oan be calculated 










Shipping 


Customization ot shipping cost calculation policy 


10 










1 ax o en be calculated on a line by line basis 


0 








lax 


Interact with ad servers to oross-eeii and up-eetl 










lax 


Interact with ShoppingAdvisor lo recommend products 




7 






lax 


Maintain a personalized shopping lie! 




7 
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Tne table is divided into 5 major sections. The first section lists each "eFunction" and tne 
package or grouping to which it belongs. The second section lists the development status 
with regard to any pre-existing functionality in house and the importance of the feature as 
a gauged by competitors, customers, and partners. The Competitors section contains z 
column for each software solution that can be considered a competitor. For each 
eFunction an ad-hoc scoring from 1-10 is provided where 10 is a complete solution to 
that eFunction. The Customers section provides a place to record both customer- 
requests as well as cases in which customers have implemented or extended our 
components to encompass a function that we did not provide. The Farmers section is 
where opportuniues to leverage parmerships are recorded. In many cases it may be 
difficult to distinguish partners from competitors until the analysis is completed. 
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This matrix is important because it provides a single place in which all of the options are 
quantified and can be compared and contrasted. 

Action Items 

The final deliverables from the first phase include: 

1 . A list of targeted features 

2 . The team composition for the second phase. 

Once these deliverables are done, the stage is set for the beginning of the second Phase of 
theNCD process. 





Design 

Object Oriented Analysis and Design (OOAD) using UlVlL 

he focus of tins phase is to perform an in-depth analysis of the resources defined 
in the first phase. The second phase is used to refine the general descnpnons 
created in the first phase into a design document from which implementation 
can be started. From the phase one documentation, the actors and then the use 
cases will be extracted. The use cases can then be used to fill in the detail for each of die 
components that are to be constructed. 

Overview of Usage 

A more refined version of the Surnrnary of Scope from the first phase is completed. This 
defines the specific funcuonality that will, be covered in the first implementanon of this 
NCD. This allows the team to specifically state what will and will not be covered in this 
release. In addition it is often good practice to describe a future course of action for 
rmplementing extended funcuonality. 

interacting Components 

This secnon describes die refined version of die secnon ? interacting components from the- 
analysis phase. The components or other parts of the system that this component may 
not interact with will be 'filtered out in this phase. It will be a list of specific components, 
whose funcnonaiity will be needed by the component in hand. 

k Giossary of Domain Specific Terms 

It is important to begin by defining the terms that may be ambiguous or unfamiliar to the 
reader. This will ensure that the content which follows is clearly understood. 

A List of the Actors and a Description of Roies 

The individual users and or external systems that are to interact with the newly developed 
component must be listed. This includes: 

■ End users 
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K Instirutions providing a particular service 
E Specific proprietary legacy systems 
■ Systems accessed by industry standard protocols 
Such endues must be identified and their role in the business process clearly explained. 



A Collection of Use Cases 

Use cases are as defined in the Unified Modeling Language (UML). The UML is an^ 
industry standard notation for describing object orient systems. The use cases describe 
the business process in simple narrative form. The relationships between the actors and . 
the use cases are visualized in use case diagrams and then these use cases are transformed 
into interaction diagrams that describe the operations that actors initiate on objects as well 
as object-to-object operations. Their purpose is to help the developer of the system 
identify the components and the operations that will need to be performed upon them. 
For more on use cases refer to Tne Unified Software Development Process, by Ivar 
Jacobson, Grady Booch, and James Rumbaugh. In many cases it is helpful to begin the 
development of a prototype as part of the use case exercise. This prototype application 
will often take the form of a graphical front end that implements the system from the 
actors perspective. This will provide the designers the opportunity to explore the use 
cases in depth. 

Mapping Protocols to Objects 

Beyond the standard mechanisms provided in the UML for defining components, it is 
also useful to consider some other techniques designed to exploit existing message 
passing formats. In the case where an existing message format exists, such as a 
Document Type Definition (DTD) for the eXtensible Markup Language (XML), the 
following guidelines can be used to create an initial component model: 

1 . Objects should be identified from the message formats. For instance, if there are 
"New Order" and "Cancel Order' 1 messages in a given protocol it is likely a good 
idea to create an "Order" object. In many cases the existence of the telltale 
create, refresh, update, and delete (CRUD) messages signify that there is some 
underlying entity that needs to be modeled. 

2. The methods on each object should be identified. Many times this will be simply 
translating a message such as "Cancel Order" to the "cancel" method on the 

" Order object" . Other times this might involve combining multiple messages 
into a single method call. For example, the messages "Begin Transaction" , "-tina 
Transaction" and "Update Order" might just be translated into an "update" 
method on the "Order" object that sends all three messages in the appropriate 
order. 
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3 . The identity of the remote object is captured in a set of attributes that capture the 
primary key of the entity. Typically the values will be named appropriately as 
"identified, "name", or "key"" 

4. Look also for session based components that simply specify that some action is 
to be performed but do not identify an entity. 

Initial UML Models with Documentation 

Once the use case analysis is complete the initial component models will be completed 
using the UML class diagrams and the Theory Centers specialized stereotypes. The 
process of applying the Theory Center s mapping of UML to Enterprise Java Beans is 
described in the document 'Modeling with eBusiness Smart Components". 

Test Cases 

The creation of test cases is the last deliverable in the design phase. The test cases 
provide an important validation of the design. By designing the test cases before 
implementation begins, the Quality Assurance team is given an opportunity to have input, 
into the design before implementation has begun. Performing this simple step early on 
lays the groundwork for having high quality components. 



Design Review 

The completion of the Design Phase is marked with a formal review. All of the above 
deliverables are reviewed for content and form. The design review will include senior 
development staff from Engineering, Architecture, and Professional Services, as well as 
representatives from the Sales and Marketing teams. This will provide the opportunity 
for the organization to provide additional feed back before implementation begins and to 
buy in to the target components 



THE NCD PROCESS 




implementation 

Building the New Components. 

The third phase of the New Component Development is the implementation of 
the components themselves. At this point in the development the relauonal 
mappings and deployment descnptors are generated. This will include the 
definition of securitv roles. A complete set of unit tests that exercise the 
funcuonality will be included. This phase may be completed in parallel with 
implementation of a reference implementation. The implementation will proceed within 
the following guidelines. 




ComDonent Generation 

The first step is the creauon of implementation is the generation of the classes that 
^esentmLomponentsandmorJavaDoc from the model. The components are then 
comDiledanddeployed^mmesimplestformofpersistence. The compleuon of 
depbyable components makes it possible to begm the implementation, unit test creauon 
and documentation in parallel. 

Deployment with Container Managed Persistence (CMP) 

This involves installing the bean class and its supporting classes in the EJB server with 
«r-manaeed persistence. Using tins type of persistence, the container must Keep 
So4«= andthe database synchronized i.e, the container is responsible to 
from the database and put it in the bean and also to write the dau back to me database 
(the ejblmdf) and ejbst^f) methods will not be used to access the database) . Tros is tn r patn 
ofSSSsunJ implements that allows the creauon of a non-opumized soluuon 
that can be used in the creauon of business logic, unit tests and the reference 
implementation. 

End User Documentation 

Tnis involves creating documentarion that is targeted at the end-user developer, ine 
iZZZion teanTwill use the design documents and the ,ava documentauon ana 
D r^eitforconsumouon'^oui,iderpame, Tne documentauon to this point has 
been focused on determining what the functionality should be. As such it contains 
references to functionality that we may cnoose not to implement and proauct 
comparisons that must be eliminated. 

Unit Test Construction 

Tn^OAteamwiUbegkmedesignofteststr^t^ Tius , 

2:2s begins before^ components have been fuU implemented It is important tna. 

tfst plans be created and wntcen by ^ team that is not Diased by knowing me 
unplementauon details of the components tie,, "black-box' testing). 

implement Business Logic/Legacy System integration 

Lew svstem inteerauons is concerned with the integranon of legacv applications and _ 
o£a Sto a distributed computing environment. In many instances tne ?f*g°*^ 01 

business logic will not be object-onented but must appear to oe oDjeci-onentea in 
Ss^Ied enwonment as these applicauons are of greater us, te«?o» 
~an b- used as a "wrapped to make these applicauons appear as tnough they are oDject- 
BuLsslo|c P may be added in the form of methods and tne tmpiementation o 
this business logic amounts to functional substance to the components. 



Documentation Verification 

Unon completion of the implementation and the documentation the two must be 
W^Tackmto svnch. TLis should focus on confirming than the documentary 
itches ttolem^tanon, as adtiiuonal details may have been uncovered aunng 

linif T**st Verification , 

Upon completion of me implementation and the unit tests, the components must be 

verified. 

SSSrf a reference .mplementanon usmg Ae components and the pacing 
with reeard to oW.oyment sets is the final phase of the ■mplememanon. 



Demonstration 



Creating a reference implementation 

The final phase of the NCD process invokes the creauon of a demonstranon appiicanon that 
fully uuLs the components in a functioning appiicanon. This is a nnal step that proves out 
the desien and make! -the components accessible to the business popukuon. A duierent team 
than those who built die components should assemble the appiicanon. This will help tc . 
ensure that the documentanon and design will make sense to our user community. A ny 
required changes to the design or documentanon will be made in an update that rokows. 

In man, cases the development of the demonstranon appiicanon can begin prior to the co-pienon of 
t W-entanon. In narucukr the design of the user interface and the logical flow wrH be basest: 
S^documentanon that results from the design phase. Beginning this process as early as posstaL-. 
will help to discover anv flaws in the design before the implements has proceeaed too ia=. 




Release and Support 



ReleasmglhepvdiMtocusim^ 

One- the oroduct development is complete and a reference implementation has been 
creates \z must be released. This includes the gathering of the documentation, updates 
to the release notes fas needed), creauon of the installable image (e.g.: an InstallSnieid 
image), final testing of the installable image, and distribution of the product (e.g.: we b 

release). 

After release customer support must help with installation issues, configuration and usage ^ 
problems. Also, customer support must funnel bade bugs, requests for new features and otne." 
comments and suggestions from the customers to the rest of engineering. 



Appendix A 



Versioning of Components 



introduction 



It is in both our customers' and our best interest to keep our customers on the newest 
versxon of our components. It is in our customers' best interest because they get the lares, 
and the neatest. This might include not only new functionality, but also bug nxes to code 
tW already use, performance improvements, support for new platforms, etc. It is in our 
interest because no matter how few versions of our software we want to support, in realty 
we must support whatever versions our customers are using Therefore having them ah on 
le newest version (or at least almost the newest version) will greatly reauce the number ot 
releases we must support. 

In any product, managing backwards compatibility such that development progress is not 
hated and current customers are not angered by the constant changes is a difncult challenge. 
The challenges become greater as the software product includes more programmaDility - it is 
e^erTchige one's mouse motions to accommodate GUI changes than it is to reprogram 
aU of one's Excel macros because the macro language just changed. Our components ny 
ten very nature, are used as integral portions of large and complex programs making 
5ZaS backwards compatibility for us an even greater challenge for us than it is for most 
software vendors. 

This situation is complicated by the fact that we are developing new releases at a very rapid 
raS Gently four Per year. This means that if we only support 12 months jortn o: 
product we would end up supporting three or four active products while we are in me 
S developing vet another. Such a support effort will surely grind us to a halt, rurtliermore, 
as our customer base continues to grow, we must make upgrading to new versions easy, 
predictable and desirable. If not we will spend more and more ot our time handhoioing 
the ^stomer through upgrades, explaining to them what the problems are as they it- to 
upgrade and arm-twisting them to upgrade. 

Th^ remainder of this document describes an approach to developing new versions of our 
components that would trvto make upgrades easy, prediaable and aesirabie. Tne approacn 
^s based off of the' recognition that there is a tradeoff between tne complexity ot 
C s we can add to a released the ease with which the customer can upgrade. That i, 
the more we restrict the types of changes between releases, tne easier an upgrade will oe. 

Different Types of Upgrades 

FolloW is a list of types of upgrades where each successive type of upgrade gives us more 
flexibility \e, allows greater enhancements) but also requires more work on the part o: tne 
customers when they upgrade. 



Upgrade 
Type 


Typ 

Bug 
Fixes 


es of Changes 

New 
Behavior 


Allowed 
Modify 
Existing 
Behavior 


Server 


Requires I 

Development Machine 


jpdate 

Client 


Model ana 
Software 


Bug Fix 
Only 


Yes 


No 


No 


Required 


Oniv if changes are 
needed on development 
machine. 


No 


No 


Added 
Behavior 


Yes 


Yes 


No 


Required 


Required 


Required 


Only if new 
rearures are 
used. 


Major | Yes 
Release I 


Yes 


Yes 


Required 


Required 


Reauirec J -Keauirea 



Bu* Fix Oniv: The bug fix only upgrade is characterized by the fact that it introduces no 
(let me repeat/ no") changes to the model or to the behavior of any method. It will typically 
consist of bu* fixes only althoush performance improvements, documentation changes and 
other modifications are also permissible. Belongings, being both server and client entities, 
cannot be upgraded at all. The user can install a Bug Fix upgrade without changing any coae 
or doina anvthing to their Rose models. They just install the product on the server ana 
developer machines and continue working as before. Some releases will not even neea to oe 
installed on the developer machines. For example, performance improvements or nxes ior 
bugs that only happen when the component is under heavy load are probably not neeaea or 
the development machines. 

Added Behavior: In addition to allowing for bug fixes, this upgrade type allows for the 
addition of new classes as well as for the addition of new methods to existing classes A nev 
method is either a- method of a new name, or a new overload for an existing method. Tms 
rye- of upgrade does not allow for the deletion of an existing method or tne changing or 
behavior of an existing method. Since this type of upgrade allows a class denniuon to 
change it will need to be installed on all servers, clients and development macnines. 

Major Release: This is an all-is-fair release. That is, this release makes no commitment to 
backward compatibility in anyway. It will need to be installed everywhere and existing coae 
will need to be ported to the new components. 

Please note that this should not be misconstrued as an exhaustive list of all upgrade types. 
Th- thre- unmade types discussed here have close cousins, each with slightly diiierentry 
semantics, For example, we could have a Client Bug Fn: upgrade that would oe just use a 
B U a Fix up-rade but it would have to be installed on each client and developer maenme as 
wet This would allow, among other things, changes to Belongings. Another • possible 
up-rad- typ° would be a New Component upgrade that allows bug nxes and tne adoiuor, 01 
new components but does not allow changes to existing ones. The three upgrade Type- 
discussed here are just three reasonably spaced points across the broad spectrum 01 possiDie 
upgrade types. 



Naming the Releases 

Note: This section is pendwg inhrnanai about versionmg and. naming front BE A . It will be adjust to 
satisfy any BE A conventions as needed. 



The releases should be named to inform the customer what type of changes they are getting 
in an upgrade, how major the changes are and how difncult the upgrade will oe. The 
following naming convention meets these requirements: 





Type of Release 


Examples of 




Release Name 


Bug Fix Only 


Dot-dot release . 


2.0.1, 2.3.5 


Added Behavior 


Dot release 


1 2.1.2:2 


| Major Release 


Dot-on release 


I 2.0.3.0 



Technological Assistance 

We can use some technological solutions to simplify the implementation of these policies in 

the f oUo ^™J* he up?rade easy {or the CUSK)mer by sunphfymg the work they need to do 

to upgrade existing models in Rose. _ 
o Ensure that we do not violate a release's constraints, ror example, we must 

ensure that a bug fix release does not add new methods or ; object^ ^ 
3. Simplify the cost of upgrading to the next major release bv allowing lor parake, 

development. 

Upgrading Rose Models 

When a user wants to work with our components in Rose they do so by utilizing our ..A: 
fiifcos Categorv files). By domg this, the model for our components are storea in 
different files than the model for the users components and cksses. By upaating our .CAx 
ffl^s we 1 cause Rose to add both new components as well as new behavior to existing 
components without reauinng the user to make any change in their model. Once the .^r 
fZ aie updated, the next time the user opens a model utilizing our components tney wiL 
see the upgraded model. 

ensuring a Reiease's Constraints Are Met 

The constraints on an Added Behavior upgrade are that the behavior oi existing metnoas is 
kept the same and that no methods are deleted. Unfortunately it . impossible to ensure tn, 
- the behavior of existing methods stays the same .remember the Halting Prob em). We can 
howe e write a tool to ensure that no methods are deleted. The tool woula simoiy run 
favap on the old and new class definitions and compare the output (this is tackier man * 
^plelfTerence but not difficult). A bug fix release has the added constraint that k aoes 
L/change any class definitions at all. Another tool (or the same tool with afa 
option) would do a difference and ensure that the class definitions nave not cnanged a. aL. 

Parallel Development , , . . . 

A maiorrelease places a large burden on the customer because they must, retro* men- moo* 
andT corresponding code. Because of this, we cannot expect tnem to upgrade an entire 
lar-e svstem all at once. There are three scenarios tor partial upgrades: 
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a) A developer might begin work using a new major release of our components while 
still maintaining a release using an older release. It would be convenient if they could 
do this on the same machine. 

b) If they are running multiple applications on their web server, time may force them to 
upgrade some applications but not others to the newest major release. 

c) They may wish to upgrade some parts of a system to the new components but not 
the rest. That is, they may wish to have a single application that uses multiple 
versions of our components. 

By changing our package naming scheme to include the Major Release number we can 
ensure that two release/ of our components can reside in the same VM This wuUnaolt 
scenarios fa) and (b) above. Enabling the partial upgrade described in (c) is signmcantry 
harder and while perhaps possible (through the use of the Adapter pattern), will not D e 
further discussed here. 



Conclusion 

This versioning scheme is far from complete. Investigation still needs to occur to determine 
exactiv what should and should not be allowed in each type of upgrade. For example, 
should we not bother with Bug Fn: upgrades and instead have Client Bug Fix upgrades' me 
trade-offs need to be better understood before final decisions can be made. Furtnermore, 
this scheme is limited to versioning of our components. A similar scheme will need to be 
developed for our tools. 

That bein* said, this versioning scheme, has two key features, predictability and ease of 
installation It is predictable because our customers can tell simply by comparing version 
numbers what types of changes are in a new release as well as what the complexity 01 tne 
upgrade will be. By easily being able to upgrade to new minor releases (i.e.: aot ana aot- 
dot) we can <reatly limit the amount of support we provide. For example, if, in a year we 
release 2.C, 2.0.1, 2.1, 2.2 and 3.0, we can tell our customers that we only are supporting -.1 
and 3 0 Due to' the backwards compatibility constraints of minor releases all 2.x customers 
using versions prior to 2.2 can easily upgrade to 2.2 without jeopardizing their work pre, or 
course, will never introduce a regression and will assure our customers of that ©). 
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